It is well known to use a server computer to execute one or more applications to handle requests by remote users. The applications may interface to the user via web pages which are displayed on the users' workstation by a web browser. The applications may also provide other types of information, such as files, to the user.
Typically, a user makes requests to an application (or “web”) server for an application by specifying a Universal Resource Locator (URL) corresponding to the web server and the specific application on the web server. The portion of the URL which follows the server specification is the Universal Resource Identifier (URI). In some cases, the URI may correspond to a file which is used by more than one application, and the URI does not correspond to a single application. A logging function in the web server (for example, IBM Web Sphere for dynamic parts and IBM HTTP server function for the static parts) keeps a log of the source IP of the requester, the URI in the request and the time the request was received. If the request is for a static web page or graphic, an HTTP server function in the web server forwards the requested data to the user. Typically, a web page has a static template, and various fields or frames in the template which are generated dynamically. In some cases, a “servelet”, which is part of the application, generates the fields or frames of the template dynamically. After the web page elements are fetched (in the case of static elements) or generated (in the case of a dynamically generated elements), the application invokes a communication service in the web server to return the web page or file to the user. The logging function in the web server (for example, IBM Web Sphere for dynamic parts and IBM HTTP server function for the static parts) also records the number of bytes of the web page or file that were uploaded/returned to the user in response to the request.
It was known to execute multiple applications in a single server, where there is a separate “owner” of each application. The owners can be different companies or different billing entities within the same company. It was known to bill the owner of each application based on the amount of computer and/or network resources consumed by the application during the billing period.
For example, it was known to bill the owner of each application based on the amount of processor time that each application consumed by its execution. This was done by running a separate instance of the web server process for each application, and recording the processor time utilized by each application's web server process. However, this method significantly reduces the number of applications which can simultaneously share a server computer because each process generates significant overhead for the system.
It was also known to bill the owner of each application based on the amount of data that each application caused to be uploaded to clients. This can be implemented by running a separate instance of the web server process for each application, which as stated above adds significant overhead. Also, it was known to bill the owner of each application based on the amount of data each application caused to be uploaded to clients by separating each application into a separate server IP address or domain name (even if all of these different addresses all point to the same physical server). This solution can be used by organizations who want to bill separate divisions or business units yet provide a common server name for all applications to their users on the Internet.
A known Distributed File Service (“DFS”) program by The Open Group checked metadata of files to determine the application which owns the files, and then billed the application owner for the storage of the files.
It was also known to bill the owner of each application based on the resources used by a virtual machine or logical partition (LPAR). Some types of computer systems are logically partitioned by a central operating system into separate, “logical” computers. A logical partition (“LPAR”) can be established in a virtual machine or non virtual machine environment. Each logical partition comprises a share of the computer resources, and executes a guest operating system and application(s) using that share of the computer resources. For example, each LPAR may be given a periodic, time slice of the system's processor(s) to execute the operating system and application(s) within the logical partition. So, if a computer system is logically partitioned into ten logical computers, and each partition has an equal share of computer resources, then each logical partition can be executed on the processor(s) ten milliseconds every hundred milliseconds. In this manner, the applications within each logical partition execute as if they have their own dedicated computer resources (although the applications may be dormant ninety percent of the time). Alternately, if there are multiple processors in the system, each logical partition can have some of the processors dedicated to it.
The “share” of system resources for each logical partition is generally specified by a systems administrator during or before Initial Micro code Load (“IML”) (but, in some cases, can be changed dynamically without IML), and this is based on an estimate of the relative needs of all the logical partitions for the finite computer resources. However, the specified share of computer resources for a logical partition may be greater (or lesser) at times than actually needed. For example, assuming the application(s) in the logical partition handle user requests, the frequency of the user requests may vary from time to time. During times of fewer requests, the applications in the logical partition may not need the entire share of hardware resources allocated to it. So, the logical partition may begin to execute during its allocated time slice, but complete its outstanding requests before the end of the time slice. In such a case, the operating system in the logical partition will notify the central operating system to suspend its execution for the remainder of the time slice. Then, the next logical partition in the sequence will immediately begin its time slice (earlier than scheduled), as will the subsequent logical partitions in the sequence. If the other logical partitions use their entire allocated time slice, then the actual share of processor time used by the one logical partition with the fewer user requests will be less than the specified share. In the case where the logical partition has more requests than can be handled in the specified share of processor time, there is not ordinarily any automatic upgrade to the allocated share of computer resources. Instead, the users and/or systems administrator may notice a slow operation for the applications in the logical partition, and the systems administrator can then adjust the specified share for the logical partition, reconfigure the logical partitions or take other action.
There are different reasons for logical partitioning. One reason is to isolate the applications in one logical partition from the applications in the other logical partitions. For example, different users can have their applications run in different logical partitions for improved reliability, security, availability, maintainability, etc. Another reason is for billing purposes. Today customers purchase computer systems with greater capacity than is required. This is done in anticipation of future peak computing demands. Customers initially register and enable some but not all of their system's Central Processors (CPs). They are then billed based on the number of CPs that are enabled, i.e. the enabled computing capacity. When customers need additional computing power (at least on a peak basis), they may register and pay for more CPs.
It was known for the computer hardware and system operating system to track and record in a system log which LPAR is currently executing and on which processor(s). The LPAR usage information was subsequently used to compute the amount of processor usage by each logical partition per hour, and therefore, whether each LPAR has the proper processor capacity. The LPAR usage information and computation of processor usage were also sent to a systems administrator.
It was also known for a guest operating system in each LPAR to track when each application begins execution and ceases execution, as “binary application indicator” information. (It was also known for another guest operating system to measure the time that each application is dispatched.) The “binary application indicator” information indicates whether the respective application ran at any time during the previous sampling period. The guest operating system recorded this binary application indicator information in storage private to the LPAR. It was also known for the guest operating system in each LPAR to track overall resource consumption in a sampling period, i.e. the amount of service unites consumed by all program functions (i.e. guest operating system, applications, etc.) in the LPAR during the sampling period. The guest operating system recorded this resource consumption information in storage private to the LPAR. A prior art software-based reporting system cross-referenced/compiled the application indicator information for the respective LPAR and the corresponding LPAR resource consumption information. This cross referencing/compiling produces a report which indicates how many service units were used by all the LPARs that executed each application during the previous sampling period. If two applications ran in an LPAR, then each application was charged for the overall resource consumption of the entire LPAR. This report was then used to determine an amount to charge the customer for the usage of each application. Customers then manually submit the cross referencing reports to the owner of the applications. These reports are input to an auditing and pricing application in a remote work station of the owner. While the foregoing process for a software-based reporting system was effective, it required that (a) the guest operating system in each LPAR track when each application begins and ceases execution, (b) the guest operating system in each LPAR track overall resource consumption of the LPAR and (c) the software-based reporting system cross reference data from each LPAR. This was burdensome to the systems administrator because there can be many LPARs in each system. Also, some reports are susceptible to customer tampering.
Published Patent Application US 2005-0004879 A1 entitled “System and Method To Monitor Amount of Usage of Applications In Logical Partitions”, published Jan. 6, 2005, by Mathias discloses a system, method and program product for determining an amount of usage of applications in an LPAR in a computer system and a bill for such usage. A guest operating system executes in the LPAR. The guest operating system dispatches a plurality of applications in the LPAR. The guest operating system or other program executing in the LPAR determines information indicative of an amount of usage of each of the applications. Based on the information, an amount of usage of each of the applications is reported to a billing function. The billing function determines a bill for each of the applications based on the amount of usage of each of the applications. An amount of usage of the LPAR is determined based on system data, without using application usage information determined by the guest operating system or the other program in the LPAR. The total usage of all of the applications in the LPAR is determined based on the information determined by the guest operating system or the other program in the LPAR. The total usage of all of the applications is compared to an amount of usage of the LPAR based on the system data, to audit the amount of usage of the applications in the LPAR or a charge based on the amount of usage of the applications.
An object of the present invention is to provide a convenient and effective technique to monitor and report usage of individual applications within the same computer, virtual machine, or LPAR, for billing or other purposes.
Another object of the present invention is to provide a convenient and effective technique to monitor and report usage of individual applications sharing a single IP name or address and a single web server process within the same computer, virtual machine, or LPAR, for billing or other purposes.